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1 INTERACTIVE ELECTRONIC BILL PAYMENT SYSTEM 

2 

3 BACKGROUND OF THE INVENTION 
4 

5 FIELD OF THE INVENTION 

6 The present invention relates to electronic bill submission and processing, and in 

7 particular to insurance claims corresponding to providers of insurance services. 
S 

9 SUMMARY OF THE INVENTION 

10 According to the present invention there is provided an electronic bill processing system 

1 1 for coordinating the submission and processing of an electronic bill corresponding to a provider 

12 of insurance services, the system comprising; 

13 a) a provider interface; 

14 b) an integrated database coupled lo the provider interface for storing bill information 

1 5 pertaining to the electronic bill; 

16 c) a workflow engine coupled to the integrated database for coordinating the processing 

17 of the electronic bill and tor updating the bill information in response to the bill 

18 processing; and 

19 d) a management system coupled to the integrated database for monitoring the contents 

20 of the integrated database accessible by the provider interface; 

21 wherein the provider can coordinate real-time retrieval of submission and status details 

22 for bill information contained in the integrated database. 
23 

24 According to a further aspect of the present invention there is provided a method for 

25 coordinating the submission and processing of a bill according to predictive payment data of a 

26 plan. The method comprises the steps of: 

27 a) storing the predictive payment data corresponding to the plan in a database coupled to 

28 an adjudication engine; 
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1 b) inseiting a predictive payment parameter into a rule set of the adjudication engine for 

2 eventual adjudication of the predictive payment data at a predefined interval, the 

3 predictive payment parameter corresponding to a content of the plan; 

4 c) triggering a creation of the electronic bill at the predefined interval according to the 

5 predictive payment parameter; 

6 d) retrieving the predictive payment data from die database and providing the predictive 

7 payment data to the adjudication engine; 

8 e) updating the predictive payment parameter for recognising the submission of the 

9 payment data to the adjudication engine; and 

10 f) generating the bill as defined by the predictive payment data of the plan once 

1 1 adjudicated. 
12 

13 According to a still further aspect of the present invention there is provided a system for 

1 4 coordinating the submission and processing of a bill according to predictive payment data of a 

15 plan. The system comprises: 

16 a) a provider interface; 

17 b) an integrated database for receiving a predictive payment plan submitted firom the 

1 8 provider interface; 

19 c) a predictive payment request of the plan storable in the database, the request including 

20 a plurality of predictive payment parameters; 

21 d) an adjudication engine coupled to the integrated database; and 

22 e) an insertion Amotion for inserting the predictive payment parameters, when stored in 

23 the database, into an adjudication rule set of the adjudication engine, the adjudication rule 

24 set for eventual adjudication of the predictive payment data; 

25 wherein adjudication of the predictive payment data results in the generation of the bill. 
26 

27 
28 

29 
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1 

2 BRIEF DESCRIPTION OF THE DRAWINGS 

3 These and other features of the preferred embodiments of the invention will become more 

4 apparent in the following detailed description in which reference is made to the appended 

5 drawings wherein: 

6 Figure 1 is an electronic bill processing and management system; 

7 Figure 2 is a component model of the system of Figure 1 ; 

8 Figure 3 is a component model for a provider bill submission interface for the system of 

9 Figure 1; 

10 Figure 4 is an example screen of the submission interface of Figure 3; 

1 1 Figure 5 is a further example screen of the interface of Figure 3 ; 

12 Figure 6 shows a Labour Management Re-entry workflow of the system of Figure 1 ; 

13 Figure 7 is a referrals workflow for the re-entry workflow of Figure 6; 

14 Figure 8 shows a selection algorithm for the workflow of Figure 7; 

1 5 Figure 9 is a manage plans workflow for the re-entry workflow of Figure 6; 

16 Figure 10 shows a first graphical user interface for the workflow of Figure 7; 

17 Figure 1 1 shows a second graphical user interface for the workflow of Figure 7; 

18 Figure 12 shows a third graphical user interface for the workflow of Figure 7; 

19 Figure 13 shows a fourth graphical user interface for the workflow of Figure 7; 

20 Figure 14 shows a fifth graphical user interface for the workflow of Figure 7; 

21 Figure 15 shows a workflow for creating a plan for the workflow of Figure 6; 

22 Figure 16 shows a furst graphical user interface for the workflow of Figure 9; 

23 Figure 17 shows a second graphical user interface for the workflow of Figure 9; 

24 Figure 1 8 shows a third graphical user interface for the workflow of Figure 9; 

25 Figure 19 shows a fourth graphical user interface for the workflow of Figure 9; 

26 Figure 20 shows a fifth graphical user interface for the workflow of Figure 9; 

27 Figure 21 shows a plan versus actuals report workflow for the system of Figure 1 ; 

28 Figures 22, 23, and 24 show a plan versus acmals repon according to the workflow of 

29 Figure 21; 
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1 Figure 25 shows tlie components of a predictive payment request for the system of Figure 

2 1; 

3 Figure 26 shows an interface for a predictive payment; and 

4 Figure 27 is a bill generation workflow of the system of Figure 6. 

5 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

6 Referring to Figure 1, an insurance bill electronic processing and management system 10 



7 has user interfaces 12, 14 for communicating over a network 16, such as the Internet, information 

8 18 related to insurance bill submission and processing corresponding to insurance claims. The 

9 user interface 14, in the fomi of a web browser, facilitates electronic submission of the bill 

1 0 information 1 8 from service providers 20 to an integrated database 26. The integrated database 

11 26 stores the bill information 1 8 for record keeping. The providers 20 provide insurance related 

12 services to workers 22 making the insurance claims. Management of the insurance services, 

13 provided by the providers 20, is overseen by a labour management agency 24. The agency 24 

14 uses the user interface 12 to manage the type and content of the bill information 18 contained 

1 5 within the database 26, as well as coordinating overall processing and access of the bill 

16 information 18. It is recognised that the workers 22 could also submit electronic biUs through 

17 the interface 14 with limited functionality. 
18 

19 The system 10 supplements the bill information 18 with general data parameters 28 

20 obtained from an insiu-ance claim database 30, a provider identification database 32, and an 

21 employers/workers database 34, The data parameters 28 are typically not specific to any one bill 

22 represented in the bill information 18, and include worker addresses, provider names and 

23 services, and insurance claim particulars. A workflow engine 36 (see Figure 2) manages the 

24 transfer of the bill information 18 and the data parameters 28 between an adjudication engine 38 

25 and a payment engine 40. The adjudication engine 38 processes any bills, related to the 

26 insurance claims, resident ui the integrated database 26 to detemiine what portion of the bills, if 

27 any, should be paid out. The adjudication engine 38 therefore receives bills from the providers 

28 20, adjudicates the provider bills according to business rules (including utilisation mles), 

29 generates adjudication resuhs for valid ^'complete" bills, and generates exception records for 
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1 invalid "exception" bills. The payment engine 40 then directs payment of the adjudicated 

2 complete bills to a financial institution 42 for subsequent payment to the providers 20 and/or 

3 workers 22. 
4 

5 Accordingly, the bill information 18 includes details related to bill status, such as pending 

6 or approved, related claim data, and bill payment particulars. The providers 20 have real-time 

7 access through the interface 14 to selected bill infoimauon 18 contained within the integrated 

8 database 26, corresponding to pre and post processing of the insurance claims and the related 

9 bills. The management agency 24 determines the degree of access by the providers 20 to the bill 

10 information 1 8 through the provider procedures 44 (see Figure 2), which defines the 

1 1 functionality of the provider interface 14. Real-time accessibility of the bill information 1 8 

12 resident on the integrated database 26 facilitates self-management, by the providers 20, of the bill 

1 3 processing history once the bills are submitted througli the interface 14 to the integrated database 

1 4 26, Therefore, the integrated database 26 acts as a repository of bill information 1 8 and 

1 5 payment information related thereto. 
16 

17 Referring to Figure 1, the management agency 24 uses a support system 1 for monitoring 

18 and setting up the electronic processing and management system 10. The support system 1 

1 9 includes a processor 2 coupled to the interface 12. The processor 2 is coupled to a display 3 for 

20 displaying the interface 1 2 and to user input devices 4, such as a keyboard, mouse, or other 

21 suitable devices. If the display 3 is touch sensitive, then the display 3 itself can be employed as 

22 the user input device 4. A computer readable storage medium 5 is coupled to the processor 2 for 

23 providing instructions to the processor 2 to instruct and/or configure the various components of 

24 the system 10, including the processes related to operation of the workflow engine 36 and 

25 interfaces 12,14. These instructions can be used to help set-up and define the protocols and other 

26 procedures related to the operation of the system 10. The compute readable medium 5 can 

27 include magnetic disks, magnetic tape, optically readable medium such as CD ROM*s, and semi- 

28 conductor memory such as PCMCIA cards. In each case, the medium 5 may take the form of a 

29 portable item such as a small disk, floppy diskette, cassette, or it may take the form of a 



McCarthy ntrauULLP TDO-RED if3205J99 v. J 



5 



Sep-OB-03 05:00pm Fron- 



T-502 P. 009 F-661 



1 relatively large or immobile item such as hard disk drive, sohd state memory card, or RAM 

2 provided in the support system 1 . It should be noted that the above listed example mediums 5 

3 can be used either alone or in combination, 
4 

5 Referring to Figure 2, the functionality of the provider interface 14 is controlled by the 

6 provider procedures 44, which are predefined by the management procedures 46 according to the 

7 desired degree of accessibility to the bill information 18 resident on the integrated database 26. 

8 The procedures 44 permii the providers 20 through the interface 14 to select bills, update bills, 

9 delete bills, and detemiine bill status once submitted to the integrated database 26. Sub- 

10 databases of the integrated database 26, directly accessible by the providers 20 in real-time, are a 

1 1 bill adjudication queue database 48 and a bill status database 50. The queue database 48 lists bill 

12 information 1 8 including all bills (and corresponding bill details) awaiting adjudication, which 

13 preferably are both read and write accessible by the providers 20. The status database 50 lists 

14 bill information 18 including a pending status (bills imdergoing adjudication), a result status (bill 

15 adjudication results), and^or a payment status (bill payment decision), which are preferably only 

16 read accessible by the providers 20. Real-time inquiry of these bill statuses and queue are 

17 accessible (defined by the provider procedures 44) by the providers 20 through the interface 14, 

1 8 with detailed breakdowns of the adjudication and payment decisions determined by the 

1 9 adjudication engine 38 and the payment engine 40. 
20 

21 Further referring to Figure 2, the management user interface 12 allows the management 

22 agency 24 to make decisions on the operation of the system 1 0, as well as select, delete, update, 

23 and inquire on selected bills submitted by tlie providers 20 and/or workers 22. The interface 12 

24 has a set of sub-interfaces of a predictive payment interface 54, labour market re-entry (LMR) 

25 interface 56, a consultation payment interface 58, and an inquiry interface 60, which are 

26 controlled by the management procedures 46 as defined by the management agency 24. The 

27 management agency 24 can also use the interfaces 54, 56, 58, 60 to update the provider 

28 procedures 44 and management procedures 46. The management agency 24 can use the 

29 predictive interface 54 and the LMR interface 56 to define and create individual adjudication 

6 
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1 rules (utilisation rules UR), related to specific codes (for example LMR codes), for insertion into 

2 the business rule set of the adjudication engine 38. 
3 

4 Referring again 10 Figure 2, the management procedures 46 provide both read and write 

5 interaction of the interfaces 54, 56, 58, 60 with the integrated database 26, Interaction between 

6 the interfaces 54, 56, 58, 60 is indicated by arrows 66, which allows for the sharing of billing 

7 data and review functionality between the interfaces 54, 56, 58, 60, includmg prepopulation of 

8 data fields. The interfaces 54, 56, 58, 60 have access to the adjudication queue database 48 and 

9 the status database 50 as described above, with further capabilities such as editing the operation 

10 of the bill queue and ameading the bill statuses. The interfaces 54, 56, 58, 60 also have access to 

1 1 sub-databases of a bill scheduling database 62 and an adjudication rules database 64. The 

12 scheduling database 62 contains data pertaining to bills removed from the queue database 48 by 

13 the workflow engine 36 for future processing, and/or data pertaining to predictive bills that are 

14 periodically inserted into the queue database 48 by the workflow engine 36 for processing by the 

15 adjudication engine 38 and payment engine 40. The adjudication rule database 64 contains 

16 adjudication rules created by the interfaces 54 and 56 in response to periodic bill parameters for 

17 predictive and labour ma2*kei re-entry (LMR) insurance claims as controlled by the workflow 

1 8 engine 36. It is recognised that data for bills related to LMR insurance claims could also be 

1 9 stored in the scheduling database 62. The degree of access for the read and write interaction of 

20 the database 48, 50, 62, 64 contents could also be limited to various access levels for individuals 

21 of the management agency 24, depending upon the individuals' priority. The access to the 

22 integrated database 26 from the interfaces 12, 14 can be determined by role based features for 

23 individual providers 20 aad employees of the managCTient agency 24, as well as state based 

24 features used as lock out features to permit sequential rather than parallel editing of the bill 

25 information 1 8 and data parameters 28. 
26 

27 Referring again to Figure 2, the workflow engine 36 monitors the data content of the sub- 

28 databases 48, 50, 62, 64 according to the management procedures 46, as well as amendment of 

29 the rule set of the adjudication engine 38 by the contents of the rules database 64. The data 
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1 content of the databases 48, 50, 62, 64 consists of the bill informadon 1 8 and the data parameters 

2 28, which are supplied by the management agency 24, the providers 20, and the woricers 22. 

3 Adjudication and payment details, generated by the adjudication engine 38 and payment engine 

4 40 respectively, are also coordinated by the workflow engine 36 into and out of the integrated 

5 database 26, as required. It is recognised diat access of the interfaces 12, 14 to the contents of 

6 the integrated database 26 is preferably in real-time. Further, access to the integrated database 

7 26 by the workflow engine 36 is preferably in periodic or batch mode to facilitate processing 

8 efiBciencies, such as providing lump sum payments to particular providers 20 related to a 

9 plurality of adjudicated bills. However, real-time access of the workflow engine 36 to the 
10 integrated database 26, for adjudication and payment results, could also be done if desired. 
11 

12 Referring to Figure 2, the workflow engine 36 coordinates, through a defined 

13 gather/insert process 66 by the management procedures 46, the gathering of all adjudication rules 

14 from the rule database 64 for insertion into the adjudication engine 38. The workflow engine 36 

15 also coordinates a scheduling process 68 for creating bills from the scheduling database 62 

1 6 contents, which are scheduled for insertion into the queue database 48 and the processed by the 

17 adjudication engine 38 and/or payment engine 40 at specified periodic intervals. The process 68 

1 8 queries a scheduled bill table of the database 62 to conjfiim which bills should be processed on a 

1 9 periodic cycle, such as a daily cycle, and build any confirmed bills using minimum bill data 

20 requirements for the bill queue of the queue database 48. Accordingly, the process 68 extracts 

2 1 scheduling data from the database 62, and then decides whether to hold the bills pertaining to the 

22 scheduling data for future action or to populate the bill queue of the queue database 48 with the 

23 extracted scheduling data. Tliis population of the queue table permits adjudication of the 

24 associated bills in sequence through a query process 70 as described below. 
25 

26 The workflow engine 36 coordinates the query process 70, which queries all bills in the 

27 database 48 ready for adjudication, both direct and predictive based. For example, the process 

28 70 will create an 837 flat file containing all bills obtained from the database 48, and then transfer 

29 the 837 file to the adjudication engine 36 for processing. The adjudication engine 36 creates an 

8 
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1 adjudication results file, such as an acknowledgemem 997 flat file, which is then reviewed by an 

2 update process 72 to determine the degree of success/failure of each bill adjudication. The 

3 update process 72 also transfers the success/failure details of the 997 file to the status database 

4 50, for subsequent review through the interfaces 12, 14. Further, the update process 72 would 

5 also insert payment details from the payment engine 40, related to the success/failure details of 

6 the 997 file. The workflow engine 36 also coordinates a purge process 74 to purge bills from the 

7 queue database 48 and the scheduling database 62 if needed- For example, the process 74 will 

8 purge all successfully processed bills firom the queue database 48 and all bill schedules firom the 

9 schedule database 62 that have passed their end date. It should be noted that the bill tables of the 

1 0 queue database 48 and the scheduling database 62, along with the query process 70 and the 

1 1 schedule process 68 provides an extraction and processing loop for bills of a predictive nature as 

12 entered into the integrated database 26 tlirough die predictive interface and/or tlie LMR interface 

13 56. 
14 

15 Referring to Figui-e 3, the service provider interface 14 has fotir sub-interfaces, namely an 

16 initiate LMR bill interface 76, an initiate bill interface 78, a bill submission search interface 80, 

17 and a void bill interface 82, The interfaces 76, 78, 80, 82 allow the providers 20 (see Figure 2) to 

1 8 directly manage electronically their bill submission and results relating to insiu-ance claims of the 

19 workers 22. Tlie interface 76 allows the providers 20 to submit bills for payment processing 

20 using an electronic version of an LMR provider invoice, such as an electronic version thai 

21 confomis to an EDI claim import (ASCX12N 837) format. The interface 78 allows the providers 

22 20 to submit bills for payment processing using the electronic version of a provider payment 

23 request, such as for example the electronic version conforming to the claim import (ASCX12N 

24 837) formal. The interface 80 allows the providers 20 to execute enquiries on their bill 

25 submissions and draft bills resident on the integrated database 26. These enquiries can include 

26 bill detail, bill history, as well as the status of bill payment submissions. Preferably for 

27 processing efficiency, real time confirmation of submissions and payment status information 

28 may not be supported, and payment detail may only be available as per a check run schedule 

29 implemented by tlie payment engine 40. The interface 82 allows the providers 20 to manage 
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1 their biU submissions through void bill actions. For example, in the case of batch mode 

2 operation of the adjudication engine 38 and/or the payment engine 40, the interface 82 wiU 

3 support same day avoidance submissions only. Capabihty could also be included in the system 

4 10 to cancel previously submitted bills once they have been removed from the bill queue in the 

5 queue database 48 for adjudication by the adjudication engine 38. Accordingly, the interfaces 

6 76, 78, 80, 82 allow the providers 20 to capture bill detail, save draft bills, export bill detail to the 

7 adjudication engine 38, void bill submissions, and query bill detail and payment status. 
8 

9 Referring to Figure 3, the interface 78 has functionality defined by the provider 

10 procedures 44. In particular, the interface 78 has a bill details function 84 of the procedure 44, 

1 1 which allows the providei-s 20 to initiate payment requests that are subject to invalid data, create 

12 payment requests and save submissions, create payment requests and exit submissions, create 

13 and submit payment requests subject to an incompletion, and successfiiUy create and submit 

14 payment requests. It is understood that the bills are submitted in response to the providers 20 

15 perfoiming or otherwise providing service, treatment, or products to the workers 22, It is 

1 6 understood that the workers 22 claims are established witla the management agency 24 prior to 

17 submitting the bills, and the worker/claim entitlement information has been previously loaded 

1 8 into the adjudication engine 38 and the integrated database 26. The result of the details function 

19 84 is either a payment request saved as a draft for future submission or a payment request that is 

20 submitted for processing through the interface 14 to the integrated database 26. Further, the 

21 providers 20 can use a combination of claim/worker data to submit the bill requests. It is 

22 recognised that the details function 84, and other functions as described below, could be 

23 represented as software modules for use by the support system 1 , 
24 

25 A first operation of the function 84 is to indicate that a combination of claims/worker 

26 data 89, 9 1 in the payment request inputted by the provider 20 is invalid. Referring to Figures 4 

27 and 5, the function 84 provides a submit bill menu 86 to the provider 20, whereby the provider 

28 20 enters a claim number in conjunction with worker/patient 22 profile data 91 (see Figure 5), 

29 such as date of accident, surname, given name, and date of birth, when completed for submission 
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1 to initiate the payment request. Other claim data 88 includes service codes, modifiers, ICD-9 

2 codes, date of service, place of service, units, and dollar amounts. In this instance, the profile or 

3 claim data 88 is determined to be invalid by the provider procedures 44 and the provider 20 is 

4 noiified the claim/patient information is invalid. Accordingly, die error could be the result of the 

5 combination of data 88, 89, 91 being invalid (e.g. wrong claim/worker combination), the claim 

6 number (record) not existing in the integrated database 26 (i.e. the claim has not yet been 

7 approved/fed into the appropriate components of the system 1 0), and/or a typographical eiror on 

8 the part of the provider 20 when keying in the requisite validation infomiation included in the 

9 data 88, 89, 91 . Accordingly, the invalidation process of the provider procedures 44 provides a 

1 0 validation mechanism in order for the provider 20 to proceed with the payment request 

1 1 submission. The provider 20 is given choices to continue with the request session on the 

12 interface 14. 
13 

14 Another operation of the fimction 84 is to create the payment request and then save the 

1 5 submission in draft for fixture editing/submission. Initially, the provider 20 navigates on the 

16 interfisice 14 to the bill submission component of the menu 86 and selects the submit payment 

1 7 request submenu option. The provider 20 then enters the data 88, 89, 91 and submits to initiate 

18 the payment request. The provider 20 then confiims patient 22/provider 20 profile information 

19 87, 91 and defines the bill line item information 88, such as date of service, service code and 

20 charge. The provider 20 then saves tlie payment request without submitting the bill to the 

21 integrated database 26, For example, a warning message could be displayed on the interface 78 

22 advising the provider 20 that the payment request is being saved without submitting the bill to 

23 the integrated database 26. Accordingly, the provider 20 can then retrieve and submit the bill 

24 related to the saved payment request at a later date, or can delete die draft bill via the void bill 

25 interface 82 as farther explained below. It should be noted, referring to Figure 5, that the 

26 providers 20 have the ability to input a provider specific invoice as a payment request to the 

27 integrated database 26. The data 88 can contain multiple bill line items on a per claim basis, 

28 which indicates the specific dates of service for each line and applicable modifiers (for 
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1 equipmeni) of the requests. The provider is given further choices to proceed with the request 

2 session on the interface 14. 

3 

4 A further operation of the bill detail function 84 is for the provider 20 to create and exit 

5 without saving or submitting the payment request. Accordingly, the provider 20 navigates on the 

6 interface 14 to the bill submission component of the menu 86 and selects the submit payment 

7 request submenu option. The provider then enters a claim number in conjunction witli patient 

8 profile data 91 and submits to initiate the payment requests. The provider 20 also confirms the 

9 patient 22/provider 20 profile information 87, 91 and defines the bill line item information 88, 

1 0 however, then proceeds to exit the request without saving or submitting the bill. Accordingly, 

1 1 the function 84 displays a warning message advising the provider 20 that the request is being 

12 exited without saving or submitted. The provider is given further choices to proceed with the 

13 request session on the interface 14. 
14 

1 5 A further operation of the function 84 is to initiate impaction with the provider 20 when 

16 creating the payment request, where some of the required data 87, 88, 89, 91 is incomplete. 

17 Accordingly, tlie providei- 20 selects the submit payment request firom the menu 86 provided by 

1 8 the interface 14, enters the claim number in conjunction with the pauent profile data 91 and 

19 submits to initiate the payment request The provider also confirms the patient 22/provider 20 

20 profile information 87, 91 and defines the bill line item information 88. The provider 20 then 

21 proceeds to submit the payment request, however, a warning prompt appears informing the 

22 provider 20 that the required information is incomplete and that the payment request will not be 

23 dispatched for the current claim. The provider is given further choices to proceed with the 

24 request session on the interface 14, 
25 

26 Another operation of the function 84 is for a provider 20 to create and submit a complete 

27 payment request. Once tlie provider 20 has entered the claim number in conjunction with the 

28 patient profile data 91, and confirmed the patient 22/provider 20 profile information 87, 91 and 

29 bill line item information 88, the provider procedures 44 check that all of the required 

12 
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1 information is correct and then provides the provider 20 with a confirmation prompt informing 

2 that the bill will be dispatched to the integrated database 26 for payment processing. 

3 Accordingly, the provider 20 can select OK and the bill will be submitted for processing, can 

4 select CANCEL and then edit or otherwise discard the payment request, or if the payment 

5 request has been submitted the provider 20 can retrieve from the integrated database 26 the 

6 particular payment request and void the related bill It is also recognised that a popup search box 

7 for the selection of primary service provides (POS), representing a list of providers 20 enrolled 

8 for use of the system 10, is accessible by the fimction 84 for completing the payment request. 
9 

1 0 Referring to Figure 3, Labour Market Re-entry (LMR) bill interface 76 of the general 

1 1 provider interface 14 enables LMR providers 20 to submit LMR invoices to the management 

1 2 agency 24 for payment via electronic submission provided by the system 10, The LMR bills are 

13 for service, treatment, or products provided/performed by the provider 20 according to an 

14 approved LMR plan as accommodated for in tlie integrated database 26 and the adjudication 

1 5 engine 38. The approved LMR plan includes a budget amount relating to the types of service, 

16 treatment, and/or product provided or performed by the provider 20. Each of the types is referred 

17 to as a line of service. It is recognised that the utilisation rules (UR) of the rules database 64 have 

18 been loaded by the work flow engine 36 into the adjudication engine 38 prior to submission of 

19 the LMR mvoice. The provider procedures 44 contain an LMR bill detail function 92 for co- 

20 ordinating the creation and submission of LMR invoices (payment requests). It is noted that the 

21 LMR providers 20 can identify the combination of claim/patient profile information 89, 91 to 

22 proceed with a payment request submission through the validation mechanism, as described 

23 above in relation to the function 84. Further, the LMR providers 20 can submit multiple lines of 

24 service as bill line items 88 on a per claim basis and can identify an SSP for each of the lines of 

25 service. Further, the LMR providers 20 also indicate specific dates of service for each line of 

26 service included in the data 88 as well as indicating applicable modifiers (for equipment) in the 

27 LMR invoices. In addition to that described above for the function 84, the function 92 also 

28 allows the LMR provider 20 to identify the secondary service provider (SSP) for which the bill 

29 line items 88 apply. Preferably, only one SSP is identified per bill and all line items 88 are 
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1 associated accordingly. Funher, the function 92 also operates wiiii a search popup page 94, 

2 which is supplied to the provider 20 through the interface 76. The popup page 94 aUows the 

3 provider 20 to search and select appropriate SSPs. hi addition, further popup pages of an 

4 expense code 96 and an ICD-9 98 can be provided by the function 92 to the interface 76 to allow 

5 the provider 20 to clarify and confinn portions of the data 88 corresponding to expenses and 

6 ICD-9 information. Accordingly, similar to the fimction 84, the function 92 also allows the 

7 provider to select OK for submitting tide LMR invoice for processing, selecting CANCEL and/or 

8 EDIT discard features for the LMR invoice, and if the invoice has been previously submitted the 

9 provider 20 can retrieve and void the invoice. Funher, more than one SSP can be selected 
1 0 through the popup page 94 to be included in the LMR mvoice. 

11 

1 2 Referring to Figure 3, the sub-interface 82 of the general provider interface 14 enables 

13 the providers 20, both payment requests and LMR invoices, to cancel bill submissions and/or 

14 draft bills. It should be noted, for batch mode operation of work flow engine 36 the voiding of 

1 5 bills may only be available for same day cancellations, or any other period specified for the batch 

16 mode. It is assumed that prior to accessing the VOID bill page interface 82, the provider 20 has 

17 already submitted the bill payment request, saved as a draft the bill payment request, and/or has 

1 8 decided to proceed with a same day (or other period) review/cancellation process. Accordingly, 

1 9 the provider procedures 44 allow the provider 20 to navigate to the VOID bill submission 

20 interface 82, whereby the provider 20 selects the draft or submitted bill to be cancelled via a 

21 check box (for example, "Void bill ?") and the submit a VOID request (for example by a "Void 

22 selected" button). See scenarios below discussed users guide and example screens for the 

23 interfaces 14, 76, 78, 80, 82. It should be noted that multiple bills can be voided simultaneously 

24 through the VOID interface 82. Once the VOID request has been received by the integrated 

25 database 26, a confinmation message is displayed on the interface 82 to the provider 20 thweby 

26 informing the provider 20 that the selected bills will be cancelled. The provider 20 is gjven the 

27 option to select OK for the bills to be cancelled or to select cancel so that the VOID selections 

28 will be cleared and therefore not voided from the integrated database 26, through operation of the 

29 process 74 implemented by the work engine 36. 
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1 

2 Referring to Figure 3, the bill submission search interface 80 of the general provider 

3 interface 14 enables the providers 20, for both payment requests and LMR invoices, to 

4 investigate the adjudication and payment status of bills submitted to the integrated database 26. 

5 For batch mode operation of the work flow engine 36, real-time confirmation of submissions and 

6 payment status information may not be supported. Moreover, payment detail may only be 

7 available as per a check run schedule as implemented by the payment engine 40. The interface 

8 80 has a bill submission search results function 100 as part of the provider procedures 44. The 

9 function 100 allows the provider 20 to retrieve bills/payment details from the databases 48, 50 of 

10 the integrated database 26 by a variety of search parameters, such as claim-invalid, claim 

1 1 number-valid, date range-invaKd, data range-valid, status-invalid, status-valid, claim number and 

12 date range, and status and claim number. It is further recognised that other combinations of 

1 3 search parameters, including or excepting those above, can also be used for treating the 

14 bill/payment details from the integrated database 26. It is noted that SDT inquiry functionality 

1 5 and design can be leveraged for the provider 20 inquiry implemented by the interface 80. The 

16 search function 100 co-ordinates the display of either a bill details page 102 or a payment details 

17 page 104 on the search interface 80. 
18 

1 9 Operation of the function 1 00 is initiated when the provider 20 navigates to the bill 

20 payment inquiry component of the menu 86 of the general interface 14 (see Figure 4). The 

21 provider 20 enters a claim number to fiher the claims by and then submits. However, in one case 

22 the claim number entered may be invalid, and therefore an error message is displayed on the 

23 interface 80 by the search function 100 informing the provider 20 that no bill exists for that 

24 claim. The provider 20 can then select different claim numbers or parameters and then rc- 

25 submit. Accordingly, the provider 20 can investigate adjudication results and payment details 

26 for submitted bills. An alternative to the above operation is when the provider 20 enters the 

27 claim number to filter the claims by, which contains a valid claim number, and therefore a list of 

28 bills is provided by the fiinction 100 for the ^propriate claim number for display on the 

29 interface 80. The interface 80 can display the inquiry results as tiie bill detail page 1 02, the 
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1 payment detail page 104, or a combmation of both. Further, upon the inquiry for a valid claim 

2 number. The provider 20 can narrow the search by the findingAnodifying additional criteria. As 

3 well, the provider 20 can select a particular bill (such as a link pertaining to a particular bill ID) 

4 to be viewed in greater detail. Accordingly, the function 100 interacts with the bill detail 

5 function 84 or the LMR bill detail function 92 to retrieve the requested bill detail. Alternatively, 

6 the provider 20 can select a paid amount (such as a link for a particular payment) to be viewed in 

7 detail. The function 100 can then interact with the bill detail function 84 or the LMR bill detail 

8 fimction 92 to retrieve required details for display on the bill detail page 102 or the payment 

9 detail page 104 on the interface 80. 
10 

11 A further operation of die search function 100 allows the provider 20 to retrieve 

12 bills/payment detail information by date range. The provider 20 enters a start/end date range or 

1 3 uses a calendar control to select a date to refine the search results by, and submits through the 

14 interface 80. The search fimction 100 then checks the date range against the bill details stored in 

15 the databases 48, 50, and for example can return with an invalid date range entered by displaying 

16 an error message on the interface 80 mforming (he provider 20 that no bills exist in the integrated 

1 7 database 26 for the date range selected. The provider 20 can tlien select a different date range or 

1 8 parameter and re-submit on the interface 80 through the search function 100, An alternative to 

19 the above is when the date range entered by the provider 20 is considered valid by die search 

20 function 100. In this case, a list of bills previously submitted by the provider 20 for the date 

21 range parameters selected is displayed on the interface 80. Accordingly, the provider 20 can 

22 narrow the search by defining/modifying additional criteria and can select either a particular bill 

23 and/or a particular paid amount to be viewed in greater detail. It should be recognised that 

24 multiple bill/payment details can be accessed through the general interface 14 simultaneously, as 

25 long as they correspond to the selected search criteria submitted through the interface 80 to the 

26 search function 100. 
27 

28 A further operation of the search fimction 1 00 is retrieving bill/payment detail 

29 information by status. The provider 20 selects the status range to filter submitted/draft bills by 
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1 and then submits this to the search function 100. The search function 100 then proceeds to 

2 review the contents of the databases 48, SO. If the status selected is invalid, then an error 

3 message is displayed on tlie interface 80 informing the provider 20 that no bills exist for the 

4 status selected. The provider 20 can then select a different status or other parameter and re- 

5 submit the new search criteria to the search function 100. An alternative to the above is when 

6 the status criteria are considered valid by the search function 100. In this case, the status selected 

7 produces a list of bills matching the selected status, subsequently displayed on the search 

8 interface 80. As note above, the provider 20 can then narrow the search by defining/modifying 

9 addition search criteria and/or can select particular bills and/or paid amounts to be viewed in 
10 greater detail. 

11 

12 A farther operation of the search function 100 is to retrieve bill/payment detail 

13 information from the databases 48, 50 by claim number and date range. Accordingly, the 

14 provider 20 enters a start/end date range to refine the search results and then enters a claim 

15 number to filter the claims by and then submits the search request to the search function 100. 

16 The search function 100 then searches through the databases 48, 50, and if valid, provides a list 

1 7 of bills previously submitted by the provider 20 for a given claim during the date range 

18 parameters specified for display on the interface 80. As noted above, the provider 20 can narrow 

19 the search further by defining/modifying additional criteria. Another operation is that the 

20 provider 20 can retrieve bills/payment detail irrformation by specifying status and date range. 

21 Accordingly, the provider 20 enters into the interface 80 a start/end date range to refine the 

22 search results, then selects a stams range to filter submirted/draft bills by, and then submits the 

23 search request to the search fimction 100. The search function 100 retrieves the matching bills, if 

24 valid, from the databases 48, 50 with a selected stams during the date range parameters for 

25 display on the interface 80. The provider 20 can then narrow the search by defining/modifying 

26 additional criteria as noted above. A fintlier operation of the search function 100 is to retrieve 

27 bill/payment detail information by status and claim number. The provider 20 enters a claim 

28 number to filter claims by and submits and selects a status range to filter submitted/draft bills by 

29 and submits. For a valid combination the claim number/status criteria is searched by the search 

17 
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1 function 100 in the databases 48, 50 to provide a list of bills usually submitted by the provider 

2 for a given claim during the given status for display on the interface 80. As noted above, the 

3 provider 20 can narrow the search by defining/modifying additional criteria. 
4 

5 A further operation of the search function 100 is to retrieve a saved payment request, 

6 modify the bill detail, and the submit to the integrated database 26 for payment processing 

7 through the work flow engine 36. This operation can be done by the provider 20 when bills have 

8 been created and saved for future processing. Accordingly, the provider 20 navigates to the 

9 bill/payment enquiry component of the menu 86 and then proceeds to enter a combination of 

1 0 search parameters to retrieve a list of bills (both active and pending). The parameters can 

1 1 include claim number, bill status, data range, and provider information. The provider 20 can 

12 then select from the list displayed on the interface 80 a particular bill with a status of pending. 

13 The details of tlie pending bill are displayed on the interface 80 and the provider 20 can make 

14 any necessary changes/additions of the draft bill. The provider 20 is then given the opportunity 

15 to submit the payment request, if the bill request is now complete, and then a confimiation 

16 prompt can appear on the interface 80 informing the provider 20 that the bill will be dispatched 

17 to the management agency 24 for payment processing. The provider 20 can select OK and the 

1 8 bill will be submitted to the integrated database 26 for processing, can select CANCEL and 

1 9 thereby edits/discard the bill, or if the bill has been submitted previously the provider 20 can 

20 retrieve and void the bill using the void interface 82. 
21 

22 The following outlines example interface 14, 76, 80, and 82 screens for a first scenario of 

23 submitting the payment request, a second scenario of submitting an LMR invoice, a third 

24 scenario of bill payment status enquiry, and a fourth scenario of voiding a bill. Further to that 

25 ah-eady described above, the scenarios 1, 2, 3, and 4 demonstrate the ability to provide multiple 

26 bill line items per claim for display on the appropriate interface 14, 76, 78, 80, 82, and tlae 

27 interaction of popup boxes for service code searches, date of service selections, LMR expense 

28 codes, and provider searches. Further, the enquiry and void scenarios allow the retrieval and 

18 
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1 subsequent selection of multiple bills per page, as displayed on the appropriate interface 80, 82, 

2 to facilitate easy of selection by the provider 20. 
3 

4 Further, an application user guide is provided for the LMR submission interface 76, the 

5 bill submission search interface 80 and void interface 82, appropriate either to LMR and/or bill 

6 payment requests. It should be noted, that the user guide explains further functionality of the 

7 system 10 such as printing a screen with bill infoxmation 18 contained thereon, and system 10 

8 login for providers 20 part of a provider database having access to the system 1 0. It should be 

9 noted that registry opportunities for an unregistered provider 20 is also presented on the general 

10 provider interface 14. It should be noted that the user guide should be considered as one 

11 example of system 10 application to a specific management agency 24. Accordingly, some of 

12 the required criteria for entry into the data fields as displayed on the interfaces 14, 76, 80 may be 

1 3 other than those shown. 
14 

15 Also provided in this disclosure is an example implementation of the system 10 for 

16 provider bill submission UI web specification and error/warning messages. The web 

17 specification gives examples of the controls listed in the tab sequence of the menu 86 and sub- 

18 menus thereto, as well as the actions or events required on the various pages displayed on the 

19 interfaces 14, 76, 78, 80, 82 to initiate the corresponding listed responses. Further, the web 

20 specification also includes example data elements and data validation parameters. 
21 

22 Refeiring to Figiure 6, the LMR workflow 199 is shown between the worker 22, the 

23 management agency 24, and primary (PSP) and secondary (SSP) service providers. Initially, the 

24 worker 22 submits a plan request 200 to the management agency 24. The management agency 

25 then uses an adjudicator 24a to compose a plan referral 202, which is sent to a selected provider 

26 PSP, The PSP accepts the referral 202 and submits a completed or proposed plan 204 back to 

27 the management agency 24. The completed or proposed plan 204 includes a listing of expenses 

28 with corresponding SSPs, dollar amounts, start dates, and end dates. The adjudicator 24a in 

29 conjunction with a health care professional 24b reviews the plan and submits the approved plan 
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1 206 back to tlie PSP. The PSP can then sub-contract out portions 208 of the plan 206 to a 

2 number of SSPs. It is noted that thei« may be situations in which the plan 204 requires 

3 amendment and the referral 202 may be dechned, as further described below. Further, once the 

4 approved plan 206 is confirmed, a rule set 210 is sent by the management agency 24 into the 

5 rules database 64 (see Figure 2), which eventually is inserted into the adjudication rule set of the 

6 adjudication engine 38. The rule set 210 is used to identify whether bills are payable under the 

7 approved plan 206 by testing the bills against the niles. The rules include that the SSP on the bill 

8 is the same as the SSP on the line of service, that the date of service of the bill in within the 

9 range for the corresponding entry in the plan, and that the amount of the bill is less than the 
1 0 amount remaining in the plan budget for the conesponding line of serv^ice. 

11 

12 The PSP and SSP have access through the interface 14 (see Figure 2) to the integrated 

13 database 26, for subsequent inquiry of the approved plan 206 as it is processed through the 

14 system 10. It should be noted that the approved plan 206 enables the management agency 24 to 

15 pre-approve a group of bills associated with the particular LMR plan 206. It should also be 

16 noted that it is preferable that only the intended provider PSP have access to the referral 202 

17 through the interface 14. 
18 

19 Referring again to Figure 6, the LMR workflow 199 is designed to assist the workers 22 

20 who have injuries that prevent a return to work with the accident employer. The management 

2 1 agency 24 partners with the providers PSP, SSP to deliver skills acquisition and training 

22 programs. The management agency participates in the workflow 199 by initiating referrals 202, 

23 approving plans 206, monitoring programs, and helping to pay bills associated with the approved 

24 plans 206 through payors (not shown) who provide payment as specified by the payment engine 

25 40 (see Figure 2), Accordingly, the referrals 202 mark the starting point for the LMR workflow 

26 1 99, as the worker 22 receives LMR sen/ices preferably througli the referral 202 from the 

27 management agency 24 to the provider PSP. The provider PSP submits the proposed plan 204 to 

28 the adjudicator 24a who then indicates approval or requests changes. Once the plan is approved, 

29 the approved plan 206 provides the details needed to adjudicate LMR bills. 

20 
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1 

2 Once the plan 204 has been approved, bills can be submitted by the providers PSP, SSP 

3 to the IDB 26 (see Figure 1) and paid according to the details ixi the plan 206, as further 

4 described below. The providers PSP, SSP incur costs in performing the LMR plan 206 for the 

5 worker 22. The providers PSP, SSP can then submit their bills through the interface 14 to the 

6 IDB 26 for their own expenses and for expenses incuirad on behalf of the worker 22, The LMR 

7 bills are adjudicated by the adjudication engine 38 (see Figure 2) and payment is determined by 

8 the payment engine 40 according to the rules established 210 previously upon plan approval. 

9 LMR bills that fall within entries in the plan and match plan requirements are approved by the 

10 adjudication engine 38 for payment. The rules 210 verify that the bills fall within the date 

1 1 requirements and budget requirements of the plan. Other bills are sent to a person for a manual 

12 check of the bill's eligibility for payment. 
13 

14 Refening to Figure 7, a send referrals process 212 starts 214 where the adjudicator 24a 

15 creates 216 the LMR referral 202 (see Figure 6). The adjudicator 24a submits 21 8 the referral 

1 6 202 for review by the nurse case manager 24b, who completes 220 the review and returns 222 

17 the referral 202 to the adjudicator 24a. The adjudicator 24a receives 224 the referral 202 and 

1 8 sends 226 the referral 202 to the provider PSP, who can retrieve 228 the referral from the 

19 interface 14 (see figure 1) of the system 10, If the provider PSP accepts 230 the referral 202, 

20 then tlie referral 202 is assigned 232 to a consultant of the provider PSP to generate 234 the 

21 proposed plan 204. Further, the adjudicator 24a is notified 236 that the referral 202 has been 

22 accepted and the referral process 212 ends 238. Otherwise, the provider PSP declines 242 the 

23 referral and an alternate provider PSP is selected 244. This selection 244 continues until 

24 acceptance 236 is confimied. 
25 

26 It should be noted that the referral process 212 can automatically select the provider PSP 

27 from the provider database 32 (see Figure 1). Referring to Figure 8, a selection algorithm 246 

28 accesses 248 the database 32 through a plurality of selection criteria 250. The selection criteria 

29 250 can include postal code matching 252 of the provider PSP and the worker 22 (geographic 
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1 Specific), provider expertise 254, provider selection firequency 256 for distributing a number of 

2 referrals among a group of eligible providers PSP, or any other combination of the above. It is 

3 recognised that other selection criteria can be used, if desired. Once the provider PSP is selected 

4 258, the adjudicator 24a or other system administrator can override 260 the selection. It is also 

5 possible that the adjudicator 24a manually selects the provider PSP for the referral 202. 
6 

7 Referring to Figures 10-14, an examiplc referral 202 is shown, including worker 22 

8 details, employment profile, physical precautions, referral details, as well as provider details that 

9 can be determined by the algorithm 246 (see Figure 8). 
10 

1 1 Referring to Figure 9, a manage plans process 262 starts from the previous step 234 of 

12 the referral process 212. The provider PSP creates 264 the proposed plan 204 (see Figure 6) and 

13 submits it through the interface 14 (see Figure 1) to the management agency 24. The agency 24 

14 then receives 266 the proposed plan 204. The agency 24 determines 268 a value for the 

15 proposed plan 204 and then sends payment 270 to the provider PSP for the plan set-up and what 

16 level of assessment has already been completed with the worker 22. Further, the agency 24 also 

1 7 reviews 272 the proposed plan 204 for suitabihty. If the plan 204 is approved 274, then the 

18 adjudication rules 210 arc detennined and sent to the rules database 64 for subsequent use in 

1 9 adjudicating LMR plan bills associated with the approved plan 206. The provider PSP is notified 

20 276 of the approval Otherwise, the plan 204 is declined and amended 274, and the provider 

21 PSP is notified 278 that changes are required before final approval. The provider PSP then 

22 modifies the plan 204 and resubmits 280 it for approval This change process can continue until 

23 the plan 204 is finally approved 274. 
24 

25 Further activities by the provider PSP and management agency 24 for the process 262 

26 include the provider PSP viewing the status of the submitted plan 204, 206, the provider PSP 

27 submitting plan 206 amendments as necessary after approval, the provider PSP viewing the 

28 balance remaining on approved plans 206, and the agency 24 changing the status of the plans 

29 204, 206 (i.e. cancel, suspend, reactivate). In the case of changes or amendments of the 
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1 approved plan, the rules 210 are also updated to reflect the changes. Further, during the 

2 amendment process of the plans 204, 206, aU versions of the plans 204, 206 can be stored in the 

3 ffiD 26 (see Figure 2) for referral by the agency 24 to help in subsequent analysis of the plans 

4 204, 206. 
5 

6 Therefore, as described above, the process 2 1 2 creates and sends the referral 202 to a 

7 selected provider PSP, who then either accepts or declines. Notification of ihe 

8 acceptance/decline status is given to the agency 24. Further, it should be recognised that once 

9 the initial referral 202 is created, aU subsequent status information of the referral 202 is stored in 

1 0 the IDB 26 (see Figure 2) for review by interested parties of the system 1 0 through the interfaces 

1 1 12, 14. Following acceptance of the referral 202, the provider PSP prepare and submit the 

1 2 proposed plan 204, which can consist of information pre-populated from the referral 202, an 

1 3 indication of the level of assessment completed with the worker, as well as details outlining the 

14 proposed program of care. After the plan 204 is submitted, the referring adjudicator 24a receives 

1 5 notification of the plan 204 and initial payment is given to the provider PSP base on the 

1 6 indication of the level of assessment completed. Therefore, it should be noted that the rules 2 1 0 

17 are used by the adjudication engine 38 (see Figure 2) to process the remaining level of 

1 8 assessment of the approved LMR plan 206 on a predictive basis. 
19 

20 The adjudicator 24a indicates initial adjudication results on the proposed plan 204, and 

21 have the option of either approving the plan 204or requesting changes. The approved plan 206 

22 triggers through the workflow engine 36 (see Figure 2) the creation and submission of the 

23 payment rules 210 into the adjudication engine 38. These results are also accessible through the 

24 interfaces 1 2, 14 for interested parties. As discussed above, the providers PSP can also request 

25 amendment of the approved plan 206, however, preferably the initial level of assessment remains 

26 static. If amended, the adjudicator 24a is notified of the amendments and the amended plan 206 

27 must be reapproved. It sliould be noted that the status and details of the amended plan 206 are 

28 stored in the IDB 26 (see Figure 1) for access through the interfaces 12, 14. In the case of 

29 subsequent reapproval, tlie rules 2 1 0 are triggered for change and reinserted into the adjudication 
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1 engine 38. Accordingly, the revised rules 210 replace the previous mie set 210, Further, the 

2 adjudicators 24a can change the status of the plan 206 at any time, such as to suspension or 

3 cancellation. This change in status is recorded in the IDB 26, as well as revised in the rules 210 

4 to deactivate the payment associated with the plan 206. Conversely, the adjudicators 24a can 

5 also reactivate the plan 206, if suspended or cancelled, which will also trigger the revision of the 

6 rules 2 1 0 to reactivate the payment rules associated with the plan 206, It should be noted that 

7 this change in status is also recoded in the IDB 26, Accordingly, the interfaces 12, 14 can be 

8 used by interested parties (i.e. agency 24 members and providers PSP) to inquire about the status 

9 and other details concerning referrals 202 and plans 204, 206, as well as the actual dollar 

10 amounts approved/paid against the plan 206. 

11 It is also recognised that members of the agency 24 can override any provider PSP 

12 selection, change the PSP, view a series of referrals 204 against associated valid claim numbers, 

1 3 and view plans 204, 206 and amendments for any valid claim number. Further, members of the 

14 agency 24 can also update LMR parameters of the system 10, including the referral algorithm 

15 246 operation, the selection criteria 250, as well as expense codes and dollar limits used by the 

16 plans 204, 206, 



17 Referring to Figure 15, an example creation or editing of the plan 204, 206 is shown. An 

18 example plan 204, 206 is shown in Figures 16 to 20. In general, the creation of the plan 204, 206 

19 includes: 

20 1 . User (of the provider 20 see Figure 2) logs into the system 1 0 througli the interface 

21 - 14, 

22 2, User selects tlie view or edit plan option, 

23 3. System 10 displays the following fields: Claim Number, Worker First Name, Worker 

24 Last Name on the interface 14, 

25 4. User enters worker's name and or claim #, 

26 5. User issues a Search command, 

27 6. System 10 searches for matching criteria and validates that the claim number is a 

28 valid claim number. 
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7. System 1 0 determines that the claim number is valid and displays the results to the 
user on the interface 14, 

8. System 10 displays the following fields to the user for the specific claim number: 



Section 1: Plan Header Tab (see Figure 16) 
Claim number 
Claim status 

Worker name (first and last) 
Worker DOA 
Desk ED 
Plan ID 
Plan Version 
Plan Status 
Date Plan Created 
Plan Start Date 
Plan End date 
Plan Review Date 
Plan Suspension Period 
date Plan Last Modified 
Plan Modified By 



Section 2: Payment Details Tab (see Figure 17) 

• Status 

• Service Code 

• Freq 
Unit 
Amount 

Payment Start Date 
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1 • Payment End Date 

2 • Payee Name 
3 

4 Section 3: Assessment Tab (see Figure 19) 

5 • PCA Total Amount 

6 • CA Total Amount 

7 • Rationale Notes for assessment detail 
8 

9 Section 4: CEW Tab (see Figure 1 9) provides a sununary of the various cost 

10 categories and Section 5: View Payments Tab (see Figure 20) provides summary of 

1 1 approved amounts once the plan 204 has been submitted and then reviewed by the 

1 2 adjudicator 24a (see Figure 6). 
13 

14 In order to display the actual dollar amounts approved and/or paid against the plan 206, 



1 5 the fiiciliiy to create a report called plan budget versus actuals is provided within die reporting 

16 and monitoring module (see Figure 1). The name "actuals" refers to the actual dollar amounts 

17 paid. The plan versus actuals report uses details of the plan described above and stored in the 

18 integrated database. The report also uses information on the amounts paid which are also stored 

1 9 in the integrated database. 
20 

21 Referring to Figure 2 1 , a workflow for creating a plan versus actuals report is shown 

22 generally by the numeral 320. A repon may be requested by a primary source provider (PSP) or 

23 by the labour management agency (LMA) 24. At step 322, the PSP or the LMA requests the 

24 plan versus actual report. The request includes a claim number as an indication of the plan of 

25 interest. The plan budget versus actual repon provides a view of the entire plan including 

26 budgeted amounts compjired to paid amounts. To create the report, the system determines the 

27 latest approved plan at step 324. Although the plan is the "latest approved plan", the status of the 

28 plan may be "closed" or ^'expired" rather than ''approved". The system then finds all paid bills 
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1 for the claim indicated in the request at step 326. The claim number and service code on each 

2 bill will detennine which section the bill will be counted against. 
3 

4 The system then aligns all the paid bills with the latest approved plan associated with the 

5 claim indicated in the request at step 328. The aligning process uses the bill service code to align 

6 bills with plan lines according to their service codes- The bill date of service (DOS) can be 

7 outside of the date range defined for the plan line service. The bill secondary service provider 

8 (SSP) can be different from the SSP defined for the plan line service. 
9 



1 0 This system then displays the report at step 330. A sample report is shown at Figure 22, 

11 23, and 24. The report is displayed in two sections, namely, a header and a body. The header 

12 section includes the foUowing information: 

13 *'As of: date the information that is displayed w^as updated 

14 'Worker name": l..ast and First name of worker associated with the case 

1 5 "Claim Number": claim number associated with the case 

1 6 "Plan Id*': LMR Plan Id generated by the system 

17 "Version": Version of the LMR Plan 

18 "Plan States": status of the IMR plan information displayed 

19 "Effective Dates": 

20 From is the date when the plan was last approved 

21 To relates to plan Status: 

22 Approved = open 

23 Closed = date when the plan was closed 

24 Expired = date the plan expired 

25 "Service Duration": the earhest start date of a service in the plan to the latest end date of 

26 a service in the plan. Note: Service duration can be outside the plan effective dates. 

27 "Case Manager Name and Phone": Last and first name of Case Manager and phone 

28 "Adjudicator Name and Phone": Last and First name of Adjudicator and phone 

29 "Primary Provider and Location": Name of Primary service Provider and location (city) 
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1 ^Transferred From**, "Location'* and "Transfer Date": when plan is transferred, the 

2 previoiis owner name, location (city) and date when plan is transferred. Transfer can be 

3 External (from another provider) or internal (from a different location or different Case 

4 Manager). If the case was not transferred, "n/a" will be displayed in these fields. 
5 

6 Within the body of the report are four sections, namely assessment, plan budget with 



7 actuals, other payments issued, and totals. The assessment section includes the services of 

8 transferable skill analysis, evaluation, and vocational evaluation. The report displays the service 

9 code and name of assessment services that have been paid automatically. The report also 

10 displays the code and name of the primary service provider associated with the auto-payment. 

1 1 Finally, the report shows the actual amount paid to the primary service provider. If no amoxmt 

12 has been paid, then the message "no assessment'' is displayed. 
13 

14 The plan budget with actuals section of the report displays all services in the latest 

15 approved plan with the actual amounts paid for each service grouped by secondary service 

16 provider (SSP). The report includes the service code and name according to the latest approved 

17 plan. The provider code, name and address according to the latest approved plan, the effective 

1 8 dates of the service according to the latest approved plan, the status of the service, the plan 

1 9 amount and the actual amount paid to the secondary service provider The status of the service 

20 can be "currenf "future'*, "past" or '^mallocated". The status is "current" if the date is between 

21 the start date and end date of the plan line service. In this case, the "actuals'' amoxmt is the total 

22 of bills where the DOS is between the service start date and end date, the bill service is the same 

23 as the line service, and tb.e bill SSP is the same as tlie line service SSP. 
24 

25 The status is "future" if the date is before the start date of the plan line service. Li this 

26 case, the "actuals" amount is the total of all bills where the bill DOS is between the service start 

27 date and end date, the bill service is the same as the line service, and the bill SSP is the same as 

28 the line service SSP. 
29 
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1 The status is "past" if the date is after the end date of the plan line service. In this case, 

2 the "actuals" amount is the total of all bills where the bill DOS is between the service start date 

3 and end date, the bill service is the same as the line service, and the bill SSP is the same as the 

4 line service SSP, 
5 

6 The status is "unallocated" if the bill service is the same as the line service, and the bill 

7 SSP is not the same as the service SSP or the bill DOS is outside of the range defined by the start 

8 date and end date of the plan line service or both. 
9 

10 Finally, the system calculates the balance remaining in the plan as the difference between 



11 the plan amount and the actual amount. For each separate service, the report includes a service 

12 total line which includes the total budget for that service and the actual amount paid for that 

1 3 service and the balance available for that service. 
14 

15 The other payment section of the report displays all payments made for services that are 

1 6 not in the latest approved plan. This section of the report displays the service code and name for 

17 payments made for a service outside of the latest approved plan, the code and name of the 

1 8 service provider associaterd with tiie payment, and the actual not paid. If there is no such 

19 payments then a message is shown saying "no other payments were issued." 
20 



21 The total section of the report shows the actual amount paid for assessments, the plan 

22 amount, actual amount and balance for the plan budget with actual section, the total of odier 

23 payments issued, and an overall total of all actual amounts paid for the claim. 
24 

25 As discussed above, the predictive payment process 119 (see Figure 6) is part of the 

26 system 10. The recurring payment requests associated with the LMR plans 206 are used in the 

27 administration of worker 22 claims in order to support the bill adjudication 3 8 process. There 

28 are four major functions used in the system 10 and associated process 199, including creation of 

29 a predictive payment, the modification of a predictive payment, searching for existing predictive 
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1 payments, and a bill generation process. These functions are coordinated through the interfaces 

2 12, 14 (see Figure 1), 

3 Referring to Figure 26, the following steps are performed to create a predictive payment: 

4 1. The Plan 206 Start Date is auto-populated based on the earliest payment start date on 

5 the that will be entered on the Plan Detail tab; 

6 2. The Plan End Date can be automatically populated by the system to 5 years, for 

7 example, from the Plan Start Date, This date can be modified by the user to a date 

8 other than the preset date, if desired; 

9 3. The system will auto-populate the Plan Review Date to 12 months, for example, prior 

10 to the Plan End Date; 

1 1 4. Next the user moves to the Payment Detail tab of the page (see Figure 26) and begins 

12 building the plan 206; 

13 5, User selects the appropriate service code. User may select the service code from the 

14 predefined pick list which will highlight their selection to flag to the user what they 

1 5 have chosen or they may click the Other Service Code icon which will open the scope 

16 of the service code search to all service codes. The user can search for the service 

1 7 code based on keyword and or by service code number; 

18 6. System 10 displays the selected service code in the Service Code field. The service 

19 code description will be displayed below the service code field. System will 

20 determine if selected service code belongs to a pre-defined group or "bundle" and 

2 1 will automatically pre-populates tlie next detail line items with all the service codes 

22 within that "bundle"; 

23 7, User moves to the Frequency field and indicates the appropriate frequency from the 

24 predefined pick hst (if required, this is a mandatory field but is sometimes populated 

25 by system logic); 

26 8. System 10 highlights and displays the user's frequency selection in the pick list; 

27 9. User moves to the Unit field and enters the numeric number of units to help 

28 detemiine the dollar value of the payment. For example, the unit value entered is 

29 equivalent to the total number of hours allowed for that service per month; 
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1 10. User moves to the Amount field and enters the dollar amount of the payment (if 

2 required, this is a mandatory field but is sometimes populated by system logic) and is 

3 displayed to the user. 

4 11. User moves to tlie Payment Start Date and enters the date that the first bill should be 

5 generated to begin the recurring payment cycle. A calendar icon can be available to 

6 the user in order to facilitate the user in the date selection process; 

7 12. User moves to the Payment End Date and if needed alter the default date of Dec. 31, 

8 9999 that the last bill should be generated to end the recurring payment cycle. A 

9 calendar icon can be available to the user in order to facilitate the user in the date 

10 selection process ; 

11 13. The payee field can be pre-populated with the worker's 22 name, however, the user 

12 may change payee as required (i.e. to the worker's trustee.) by moving to the Payee 

13 field. User can click on the Payee icon so that they may search for the appropriate 

14 payee. The user will be able to search for the payee based on their name (first and or 

1 5 last) and or Provider TEM# which will have already been set up for the payee whether 

1 6 they be a worker, supplier, provider or third party; 

17 14. System 10 will display the fiill address of the Payee to the user, the user will click on 

18 the payee ID and the system will populate the payee field in the Payment request 

19 Section with the fiill name of the payee; 

20 15. It is assumed that the payee will be the same for all of the payment requests. Once 

21 Payee field has been changed, the system 10 will make active a checkbox entitled All 

22 Payee , which will be checked. The user can uncheck this checkbox which means that 

23 for every payment detail they now enter for the plan 206, a payee will have to be 

24 selected and all payee name fields on the page will be deleted; 

25 16, User may repeat steps 10 - 21 for every different payment request 304 they wish to 

26 set up for this predictive payment plan 206; 

27 17. System 10 will also allow the user to *'de-select" a payment detail automatically 

28 created based on service groupings (Step 13); 
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1 18, User moves to the Rationale Tab of the page and if needed in the Rationale Notes 

2 field enter any additional information. The system will pre-populate the PCA Total 

3 Amount and CA Total Amount fields. The CA Total Amount is equal to the total 

4 amount of clothing allowance paid per year to the worker (system 1 0 adds all clothing 

5 allowance service codes to be paid for the year). This amount does not include arrears 

6 amount. The PCA Total Amount is equal to the total amount of Personal Care 

7 Allowance paid per month (system 10 adds up all PCA service codes to be paid for 

8 the month into one amount). This amount does not include arrears amount; 

9 1 9. User issues the Save command. System saves the information to the database and the 

10 predictive plan is successfully saved with a stams of "Pending'' allowing the user to 

1 1 save a partially completed plan. To activate the plan 206, user will go to the Modify 

12 Plan option and completed all required information; 

13 20. User issues the Submit command on the Rationale tab; 

14 21. System 10 can run validation checks for completeness on mandatory fields and 

1 5 formal of data entered into all fields that require population by a user and ensuring 

1 6 that no duplicate payment requests have been created; 

1'^ 22. System 10 saves the information to the database 26 (see figure 2) and the predictive 

18 plan 206 is successfially saved as "Active". 

19 

20 The create predictive payment process involves the set up of one or many predictive 

21 payment requests by the rules 210 for the purposes of the predictive payment plan for the worker 

22 22 claim. The modify predictive payment process involves the application of the administrative 

23 practices of a payor to the existing predictive plan structure they have defined for a worker 22 

24 claim. These modifications may include The following changes: modify service code; modify 

25 ft^equency; modify payment amount; modify start and end dates; modify units (where 

26 applicable); and modify payee. These items are included in die LMR DB 64 (see Figure 2) as 

27 the series of payment rules 210. which are imported into the adjudication engine 38 once the plan 

28 is confirmed. The search process involves retrieving and displaying information about the 

29 predictive payment plan 206 for the worker 22 claim based upon user specified criteria through 
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1 the interfaces 12, 14, which can be used to obtain up to date information on the status and 

2 activity of the plan 206 as stored in the EDB 26 (see Figure 2), The bill generation process 

3 involves the triggering of bill creation based on parameters defined during the predictive 

4 payment plan 206 maintenance (create and modify) processes. The bill generation process will 

5 apply logic through the workflow engine 36 and the adjudication and payment engines 38, 40 so 

6 that recurring payment requests will occur, which are associated with the details of the approved 

7 plan 206 and corresponding rules 210. 
8 

9 There are three main concepts that make up the functionality of the Predictive Payment 

10 process 1 19 as implemented on the system 10; namely referral, maintenance of predictive 

1 1 payment plans 206, and generation of bills from predictive payment plans 206. The predictive 

12 payment plan 206 (or PPP) is a collection of one or more payment requests with corresponding 

13 payment parameters such as amount, frequency, start and end dates, which are then organized in 

14 a structure for the purposes of plan definition. From the plan definition the bill generation 

15 process will then be triggered to generate bills for specific payees as per the specified 

16 frequencies and start and end dates for the payment requests that are specified in the plan 206. 

1 7 The PPP is comprehensive meaning that it will include all of the predictive payment requests that 

18 a worker 22 claim needs in order to be able to build plans 206, The predictive payment plan 206 

1 9 contains at least one predictive payment request and at least one payee. 
20 

21 Referring to Figure 25, a Predictive Payment detail 300 includes the plan that interacts 

22 through a payee 302 with the predictive payment request 304 (embodied in the rules 210, see 

23 Figure 6). The payment request 304 identifies a service code 306, frequency 308, units 310, 

24 amount 3 1 2, and payment request start 3 14 and end 3 1 6 dates. For example, the agency 24 will 

25 determine that the worker 22 claim is entitled to a Personal Care Allowance and will then set up 

26 a predictive payment request 304 by the rules 210, which will allow a recurring payment to be 

27 sent to the specified payee 302. The agency 24 can indicate during the creation process wliich 

28 Personal Care Allowance code the worker 22 will receive reimbursement for, the frequency for 

29 which the worker will receive reimbursement, the number of units, the amount of the 
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1 reimbursement, and the start date and end date for the reimbursement period. The payee 302 

2 identifies who will receive reimbursement for the predictive payment request or requests 304. 

3 The agency 24 may indicate at the plan level the payee 302 if all the payment requests 304 go to 

4 the same payee 302 or if there are multiple payees 302 per each payment request then the agency 

5 24 can indicate the payee 302 for each individual payment request 304. The payee may be the 

6 worker 22, an equipment/service suppher (such as an SSP), the provider PSP, or any other third 

7 party. 
8 

9 Referring to Figures 2 and 27, once the LMR UR rules DB 64 information has been 

10 inserted into the adjudication engine 38, in response to the approved plan 206 (see Figure 6), 

1 1 generation of bills 402 from the predictive payment requests 304 (see Figure 25) can begin, 

12 The bill generation process 400 applies logic through the workflow engine 36 at a 

13 predetermined time/schedule on a daily basis, for example, to retrieve predictive payment 

14 details (corresponding to the payment requests 304 of the plans 206) from the Bill Scheduling 

15 database 62. The predictive bill data of the database 62 is reformatted by the workflow engine 

16 40 and then inserted into the bill adjudication queue 48, for eventual LMR bill 402 creation and 

17 submission into the adjudication engine 38 for adjudication. The adjudication of these LMR 

1 8 bills 402 provides the payment engine 40 with payment details, which are used to issue 

19 payment by the system 10 to the providers PSP in response to the predictive elements of the 

20 corresponding plan 206. The process 400 uses the parameters of the payment reque$t(s) 304 

21 within the plan 206 to determine what data to insert into the payment bill entity. The process 

22 400 also applies logic in order to determine the required number of bills to be generated based 

23 on the payee combinations for the predictive payment plan 206, for example coordination of 

24 benefits (COB) that are part of the plan 206 as well as direct payment to the worker 2 and SSPs 

25 if desired. The bill generation process 400 can use standard fields and values, such as the 837 

26 EDI import process. 

27 Referring to Figure 27, the bill generation process 400 is run on a predefined firequency 

28 in order to pick up from the database 62 and send bill payment requests 304 that run on user 
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1 defined anniversary dates, as well as being able to run on specific set dates. The trigger for the 

2 bill generation will be the parameters 306, 308, 3 1 0, 3 12, 3 14, 3 1 6 in the predictive payment 

3 plan (see Figure 25). Accordingly, the automatic generation of the LMR bills 402 involves the 

4 coordinated effort between the workflow engine 40 and the contents of the IDB 26, as well as 

5 the procedures 70, 72, 74, 68 as discussed above (see Figiure 2). 

6 Referring again to Figure 27, the process 400: 

7 1 . uses the system 10 through the workflow engine 40 to trigger 404 the bill generation to start 

8 on a daily basis or other predejfined period; 

9 2. the system 1 0 checks 406 the Predictive Payment schema in database 62 of the IDB; 

10 3 . the system checks 408 each predictive payment plan stored in system 1 0 for an Active status; 

11 4. for each plan that is active the system 1 0 also checks 408 to see that all payment requests 304 

12 are Active; 

13 5 . if any payment requests 304 are not active 41 0 the bill generation process 400 does not use 

14 them for bill generation and proceeds to the next 41 1 bill; 

15 6. for each active plan with active payment requests 304 the system 10 checks 412 to see what 

16 date is contained in a Next Bill Generation Date column of the scheduMng data in the 

17 database 62; 

18 7, if the date contained in the Next Bill Generation Date column is equal/matches 414 to the 

19 current date then the system 10 flags that for this plan and payment requests 304 the system 

20 10 must generate the bill 402 ; 

21 8. once the system 10 flags that the bill 402 is required for this plan and payment requests 304 it 

22 moves 416 the date in the Next Bill Generation Date column to a Last Bill Generation Date 

23 column, hence updating 41 6 the bill generation frequency; 

24 9. next the system 10 looks at a Frequency parameter for that payment request 304 and 

25 calculates what date the next bill 402 needs to be generated on and inserts that date value into 

26 the Next Bill Generation Date column; 
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1 10. the system checks 418 for other bills 402 and steps 6-9 are repeated by the system 10 until it 

2 has collected all of the payment requests 304 that require each of the bills 402 to be 

3 generated for specific plans 206; 

4 11. next the system 1 0 evaluates if one or more bills 402 are required to be generated that 

5 day/period for that plan by confirmiug 420 the payment details in steps 12-15; 

6 12. the system 10 checks an All Payee flag for each potential bill 402; 

7 13. if the All Payee flag is set then the system 10 will skip to step 16; 

8 14. if the All Payee flag is not set ihen the system 10 looks at a payee id parameter, which 

9 denotes the identity for different payees; 

10 1 5 . for each different payee id per payment request 304 for that plan the system 1 0 can create a 

11 different bill 402; 

12 16. once tlae system 10 has determined how many bills 402 are required for one plan, it begins 

13 populating 422 the bill export table 48 in the IDB 26 with the parameters stored in the 

14 predictive payment schema of the bill scheduling database 62; 

15 17, once the system 10 has completed inserting all the bill 402 data into the bill export table 48 in 

16 the IDB, the bill generation process is completed and the query bills procedure 70 is used by 

17 the workflow engine 40 to import the LMR bills 402 into the adjudication engine 38 for 

18 adjudication 424 and evenmal bill 402 generation. 
19 

20 It should be noted that information on the processing/payment history of the bills 402 is 

21 stored in the IDE for subsequent access through the interfaces 12, 14. Further, when the 

22 predictive payment plan 206 or one of the service codes 306 witliin the predictive payjnent plan 

23 has moved firom suspend to reactivate status, the system 10 determines the start and end date of 

24 the suspension period and determines if dining this time the corresponding bill 402 was not 

25 generated For example, an activation date can be provided by the user to determine date range 

26 for bill generation for the suspended period. Preferably, if no activation period is supplied, the 

27 bill generation process 400 will assume that the reactivation period will be the full suspension 

28 period, 
29 
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1 Although the invention has been described with reference to certain specific 

2 embodiments, various modifications thereof will be apparent to those skilled in the art without 

3 depaning from the spirit and scope of the invention as outlined in tlie claims appended hereto. 
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